微前端系統架構

當你走到必須學習微前端，那你就得要面對一定程度的系統設計，就有一定的學習門檻。

基本架構

當產品規模後端已經開始使用微服務，那也滿足開始導入微前端的基本條件。而微前端本質就是靜態資源，你能夠去部署靜態資源並取得就滿足微前端的基本需求。

最簡單的微前端做法就是使用反向代理的方式轉導到指定的資源存放位置，不管是用 Apache, Nginx, IIS 都可以做路由轉向到資源位置。因為資源都是固定被擺放的，不管要放置於不同的打包節點或是跨伺服器分散部署，都可以完成這最基本款的微前端。

Assets Storage

大部分前端都是靜態資源，如果沒有採用 SSR 前提下都可以採用這樣的處理方案。首先要有可以存放靜態資源的服務 Object Storage Service，不管是 Min.io 或 S3 都是很合適的工具，或是任何 CDN 的服務也都很合適，經過反向代理轉導後，都可以很容易去承受高流量的請求。

如果是自架 CDN，隨著架構日漸擴大，也很可能很快就承受不起昂貴的請求量，可以搭配 Load Balancer，去進行動態橫向拓展，以承受更大的流量附載。此時你就要能夠監控流量和每個服務提供者的運行狀態，使用 Kubernetes 去把這些 Storage Service 建立幾個 replicas 管理，按照需要去監控管理，對於流量的掌控就會更好。

Clint Service

把 Clint Service 作為資料交換中心，背後基於 Assets Storage 的架構進行拓展。Clint Service 可以當作 Proxy，傳遞 API 和靜態資源資料。也可以是 Event Bus 的接收站，串接 WebSocket 作為資訊中轉站。而微前端的部分依然能保留 CSR 的樣態，當作靜態資源應用。

Render Service

當採用 SSR 前端架構時，元件不再是單純的 CSR Component，也就是同時要能夠滿足 SSR 情境和 Hydration。目前並沒有任一套 SSR 提供成熟的解決方案，或許未來有，但當前沒有經歷足夠的成熟度。要實作這部分建議還是採用 SSR & CSR 混合的微前端方案，可減少技術瓶頸。而其他部分的設計都與 Clint Service 大致上的架構相像，可以具備快取與資訊收發的能力。